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Foreword 


A  key  ingredient  enabling  us  to  achieve  our  Total  Quality  Leadership  (TQL) 
cultural  change  is  Integrated  Product  Development--or  IPD.  The  IPD  philosophy  is  a 
new  way  of  thinking  about  how  we  do  business  here  at  Space  and  Missile  Systems 
Center.  It  represents  a  fundamental  shift  in  focus  away  from  our  individual  stovepipe 
mentality  and  towards  delivering  integrated  systems  to  our  customers. 

This  guide  describes  a  framework  for  applying  the  IPD  approach  to  your 
activity.  It  will  help  you  understand  how  to  find  ways  to  work  more  closely  with  your 
customers;  empower  your  people;  enable  everyone  to  make  better  program  decisions; 
and  structure  your  management  data  so  Integrated  Weapon  System  Management 
(IWSM)  concepts  can  be  applied  more  smoothly. 

I  am  totally  committed  to  the  implementation  of  IPD  and  the  cultural  change 
that  it  implies.  The  IPD  approach  is  part  of  the  total  quality  methodology  we  must  use 
to  improve  both  our  products  and  our  people.  IPD  will  help  us  achieve  our  TQL 
vision--"A  Great  Place  to  Work  Where  Great  Work  is  Done. " 


Commander,  Space  and  MissUe  Systems  Center 
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How  to  Use  This  Guide 

The  purpose  of  this  guide  is  to  help  you  understand  the  Integrated  Product  Development 
(IPD)  philosophy  and  how  to  apply  it  to  your  program  or  product. 

It  is  a  reference  book,  not  necessarily  intended  to  be  read  end  to  end.  Read  those  chapters 
that  are  relevant  to  what  you  are  trying  to  do.  For  example,  if  you  are  trying  to  apply  IPD  to  a  new 
contractual  effort,  read  Chapter  2.  If  you  are  trying  to  develop  teams,  read  Chqjter  3.  We  suggest, 
however,  that  everyone  review  Chapter  1  as  the  first  step.  Tt  provides  a  history  of  the  development 
of  the  IPD  approach  as  well  as  a  description  of  the  basic  concept  as  it  is  today. 


Special 

Sections 
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Introduction 


The  Evolution  of  Integrated  Product  Development 

The  genesis  of  the  Integrated  Product  Development  Concept  traces  back  in  time  to  the 

President's  Blue  Ribbon  Commission  (also  known  as-the  PackardCommission)  on  Defense  -  - 

Management.  The  Packard  Commission  concluded  that  many  of  our  weapon  systems  cost  too  much, 
take  too  long  to  develop,  and  by  the  time  they  are  fielded,  incorporate  obsolete  technology.  Similar 
problems  plagued  selected  U.S.  industries,  most  notably  the  automotive  and  electronic.  These 
industries  improved  their  "competitive  position"  by  concurrently  designing  their  products  and  related 
production  and  support  processes. 

Prompted  by  the  Packard  Commission  Report  ("A  Quest  for  Excellence",  June  1986),  the 
Under  Secretary  of  Defense  for  Acquisition  requested  the  Institute  for  Defense  Analyses  (IDA)  to 
examine  concurrent  engineering  practices.  Encouraged  by  ID  As  recommendations  ("The  Role  of 
Concurrent  Engineering  in  Weapon  System  Acquisition",  December  1988),  the  Undersecretary 
provided  interim  acquisition  guidance  to  the  military  services  (March  1989)  concerning  concurrent 
engineering  and  its  role  in  the  acquisition  process. 

The  concept  emphasized  formation  of  multi-disciplined  teams  in  ^pport  of  product 
development.  It  was  characterized  by: 

(a)  Focus  on  the  customer's  requirements 

(b)  Quality  is  the  result  of  improving  a  process 

(c)  Process  improvement  is  a  never-ending  responsibility. 

Sustainable  momentum  for  acquisition  process  change  was  assured  when  the  Secretary  of — 
Defense  presented  the  "Defense  Management  Report  to  the  President"  (July  1989).  This  report  was 
prepared  in  response  to  the  presidential  directive  to  develop  a  plan  to  accomplish  full  implementation 
of  the  recommendations  of  the  Packard  Commission.  (This  Defense  Management  Review  also 
examined  the  improvements  envisioned  by  the  Goldwater-Nichols  Defense  Reorgamzation  Act  of 
1986).  The  directive  specifically  targeted  DOD  Acquisition  Practices  and  Procedures. 

Subsequently,  DOD  Directive  5000.1  (dated  23  February  1991),  based  on  the  principles  contained  in 
the  "Defense  Management  Report  to  the  President",  established  a  disciplined  management  approach 
for  acquiring  systems  and  materiel  that  satisfy  the  operational  customer's  needs. 

The  Integrated  Product  Development  concept  continued  to  evolve  imder  the  aegis  of  the  Air 
Force  Systems  Command.  The  Advanced  Tactical  Fighter  program  management  and  industrial 
partners  (circa  1991)  couched  the  philosophy  of  concurrent  engineering  in  an  innovative 
management  structure,  called  the  Integrated  Management  System.  It  was  through  this  mechamsm 
that  the  Air  Force  hoped  to  maximize: 

(a)  Industry  involvement  early-on  in  the  development  of  a  "Request  for  Proposal"  and 
commitment  up-front  to  an  executable  program 

(b)  Simultaneously  improve  visibility  and  understanding  of  program  risks 
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Further  maturation  of  the  Integrated  Product  Development  stemmed  from  the  Air  Force 
Materiel  Command  and  its  development  of  the  Integrated  Weapon  Systems  Management 
(IWSM)  approach.  The  White  Paper,  "IWSM  in  AFMC",  dated  January  1992,  declares  that 
System  Program  Offices  within  the  product  development  centers  "will  use  a  management 
philosophy  known  as  Integrated  Product  Development".  AFMGR  500-1 1,  dated  1  Nov  1992,- 
declares  that  the  fourth  key  element  of  the  IWSM  philosophy  is  the  use  of  Integrated  Product 
Teams. 

Definition  of  Integrated  Product  Development 

The  definition  of  IPD,  as  well  as  and  explanation  of  the  philosophy  and  its  basic  tenets,  is 
provided  below: 

Integrated  Product  Development  is  a  philosophy  that  systematically  employs  a 
teaming  of  fimctional  disciplines  to  integrate  and  concurrently  apply  all  necessary 
processes  to  produce  an  effective  and  efficient  product  that  satisfies  customer's  needs. 

Product,  in  this  sense,  is  not  only  what  is  delivered  to  your  customer  (e.g.,  hardware, 
software,  services,  and  documents),  but  also  processes  (e.g.,  design,  manufacturing, 
test,  and  logistics)  which  make  the  product  possible.  Products  range  from  complete 
weapon  systems  to  individual  end  items  and  from  request  for  proposals  to  briefings, 
as  well  as  policies  like  those  for  the  Integrated  Acquisition  Strategy  Process  and  the 
Configuration  Control  Board. 

Relationship  of  IPD  to  Other  Command  Initiatives 

IPD  shares  many  useful,  synergistic  characteristics  with  two  other  SMC  management 
initiatives:  Total  Quality  Leadership  (TQL)  and  Theory  of  Constraints  (TOC).  IPD  is  a  benchmark 
systems  engineering  process.  Within  the  context  of  the  TQL  principle  of  continuous  process 
improvement,  IPD  represents  the  process  and  resources  to  provide  rapid,  cost  effective,  customer 
focused  product  development.  Below  are  listed  the  ten  principle  core  values  and  concepts  of  total 
quality  leadership,  taken  from  the  Malcom  Baldrige  Award  Criteria,  as  they  apply  to  IPD. 

1.  Customer  Driven  Oiialitv.  IPD  stresses  a  customer  focus  and  analyzes  the  value  and  effectiveness 
of  the  total  system  from  a  customer's  perspective,  specifically  "right  product,  right  place,  light  time, 
right  price,  and  right  service". 

2.  T  paHprgViip  IPD  emphasizes  a  revised  role  for  the  organizational  leader,  from  that  of  the 
traditional  hierarchical  pyramid.  The  new  leader  is  coach,  trainer,  resource  provider  and  - 
policy/strategy  maker.  TOC  further  defines  the  new  leaders  role  as  "Socratic",  with  three  tasks: 
determining  what  to  change,  what  to  change  to,  and  how  to  change. 
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3.  Continuous  Improvement.  IPD  assumes  some  sort  of  competitive  environment  in  which  the 
customer  has  a  choice  and  increasingly  higher  expectations  for  our  products  which  demand 
continuous  process  improvement. 

4.  Employee  Participation  and  Development.  IPD  stresses  capitalizing  on  total  system  optimization 
by  involving  all  functional  skills  in  an  integrated  decision  making  process.  TQL  and  IPD  go  further 
and  stress  employee  developmenUhrough-structured  training,  experience,  career  enrichment,  and  . 
recognition. 

5.  Fast  Response.  IPD  sees  product  cycle  time  as  a  major  competitive  advantage.  It  recognizes  the 
relationship  between  cycle  time  reduction,  increased  product  quality,  lower  overall  costs,  and 
responsiveness  to  changing  customer  requirements. 

6.  Design  Quality  and  Prevention.  IPD  recognizes  this  fundamental  concept  of  concurrent 
engineering.  To  have  the  best  product,  it  is  imperative  to  obtain  and  employ  during  design  the 
expertise  of  all  subsequent  process  interfaces  (manufacturing,  test,  operational  use,  repair, 
modification,  disposal,  etc.). 

7.  Long-Range  Outlook.  IPD  stresses  that  the  organization  must  plan  on  a  long  term  horizon, 
deploy  its  energies  and  resources  through  a  quality  plan  to  achieve  the  objectives  and  constantly 
reevaluate  and  replan.  TOC  stresses  a  road  map  process  that  identifies  the  corporate  goal  and  then 
selects  where  the  organization  wants  to  have  its  system  constraint.  TOC  seconds  the  concept  of 
continuous  reevaluation. 

8.  Management  by  Fact.  IPD  stresses  flow  out  processes  and  establishing  process  check  points  to 
determine  the  health  of  the  process.  In  addition,  all  philosophies  stress  accurate  measurement  and 
open,  fear  free  communication.  TOC  emphasizes  information  particularly  at  the  system  constrainL.  . 
IPD  further  takes  management  by  fact  and  stresses  a  framework  decision  information  system  that 
integrates  all  phases  of  product  life  through  a  consistent  and  logical  product  breakdown  structure. 

9.  Partnership  Development.  IPD  speaks  to  the  power  of  integrated  teams  and  partnerships  beyond 
the  bounds  of  organizational  or  command  lines. 

10.  Public  Responsibility/and  Citizenship.  Beyond  the  active  partnerships  of  customers,  teams  and 
suppliers,  IPD  recognizes  that  the  "whole"  system  goes  beyond  the  boundaries  of  the  product,  tn 
include  the  community  and  environment  within  which  the  product  is  developed,  tested, 
manufactured,  used,  repaired,  and  disposed  of . 
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Chapter  1  -  Integrated  Product  Development  Overview 


WhatisIPD? 

IPD  is  a  management.philosophy  based  on  sound  business  practices  andxonunon  sense 
decision  making.  It  involves  bringing  the  right  people  to  the  right  place  at  the  right  .time  to  make  the 
right  decisions.  As  defined  earlier,  IPD  is  "a  philosophy  that  systematically  employs  a  teaming  of 
functional  disciplines  to  integrate  and  concurrently  apply  all  necessary  processes  to  produce  an 
effective  and  efficient  product  that  satisfies  customers'  needs."  Central  to  this  definition  are  the 
following  key  features  of  IPD: 

Product  orientation.  The  IPD  management  philosophy  focuses  on  the  products  to  be 
delivered  to  the  customer.  The  product,  however,  may  take  several  forms.  While  an  acquisition 
organization  may  deliver  hardware  and  software,  a  sustainment  organization  may  provide  a  service 
to  its  customer.  A  staff  organization  may  provide  policy  to  its  customer.  In  each  case,  these 
products  dictate  the  ultimate  success  of  the  organization  in  the  eyes  of  the  customer. 

Cross-functional  teaming.  All  functions  that  impact  the  performance  of  the  product  should 
have  a  role  in  the  development  and  management  of  the  product.  Implementation  of  this  concept 
requires  effective  teaming  between  the  functional  representatives.  The  product's  customers  and 
suppliers  should  be  members  of  the  team  to  ensure  that  product  requirements  are  xmderstood  and 
properly  flowed  to  lower  tier  organizations.  The  Integrated  Product  Team  (IPT)  then  has  the  ability 
to  make  intelligent  decisions  based  on  the  combined  input  of  engineering,  production,  logistics, 
program  management,  contracting,  financial  management,  sustainment,  operations,  and  other 
disciplines. 

Empowerment.  To  be  effective,  an  IPT  should  be  given  requisite  authority  and 
responsibility  for  its  product.  It  should  be  the  goal  of  management  to  drive  decisions  to  the  lowest 
appropriate  level  commensurate  with  risk.  Adequate  resources  should  be  provided  to  the  teams  so 
that  they  conduct  business  in  an  integrated  and  empowered  manner.  It  is  also  incumbent  upon 
management  to  ensure  proper  training  of  empowered  people. 

Upfront  planning.  IPD  requires  a  deliberate,  upfront  planning  effort  by  the  IPT  early  in  the 
product's  life  cycle.  While  the  early  phases  of  product  development  only  consume  a  small  part  of  the 
product's  total  cost,  the  decisions  that  are  made  there  dictate  over  eighty  percent  of  the  total  cost. 
Downstream  changes  to  the  product  are'extremely  costly  and  usually  require  extensive  rework  and 
reconfiguration  of  the  product.  A  key  to  this  process  is  the  transition  to  event-based  planning  that 
focuses  the  maturation  of  the  product  on  specific  events  and  accomplishments  rather  than  a 
scheduled  point  in  time. 
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Benefits  of  IPD 


Applying  the  IPD  management  philosophy  will  result  in  significant  benefits  to  the 
organization  and  the  product  it  delivers.  The  benefits  gained  from  IPD  are  consistent  with  the  . 
objectives  of  streamlined  acquisition  and  continuous  improvement. 

Reduced  time  to  field  system.  Decisions  that  were  formerly  made  sequentially,  e.g..  by 
engineering,  then  manufacturing,  then  logistics,  etc.,  are  now  made  in  an  integrated  forum. 
Downstream  changes  to  the  product  are  reduced  due  to  the  upfront  planning  between  functions.  The 
result  is  a  significant  reduction  in  the  time  it  takes  to  deliver  the  product  to  the  customer. 

Reduced  system  cost.  The  cost  of  the  system  is  reduced  in  two  ways.  First,  the  need  for 
redesign,  rework,  or  contract  modifications  is  reduced  since  all  appropriate  disciplines  are  involved 
concurrently  in  the  decision  processes.  Second,  a  reduction  in  the  time  to  deliver  the  product  to  the 
customer  will  reduce  cost. 

Improved  quality.  Smarter,  integrated  decisions  will  improve  the  quality  of  the  product. 

Programs  that  are  easier  to  manage.  The  IPD  management  philosophy  structures  the 
program’s  resources  along  product  lines  and  gives  each  team  the  authority  and  responsibility  to 
deliver  their  product.  It  also  focuses  risk  management  efforts  by  tying  risk  directly  to  the  product. 
The  day-to-day  management  of  the  program  is  simplified  by  the  integration  of  management 
structure  and  its  associated  tools. 

Implementing  IPD 

An  organization  must  undergo  a  fundamental  change  in  the  way  it  operates  to  implement 
IPD.  To  do  this,  management  must  be  successful  in  changing  the  organization's  culture  and  must  put 
in  place  a  framework  to  facilitate  the  change. 

Cultural  change.  The  tendency  of  an  organization  to  make  decisions  in  a  sequential  fashion 
has  led  to  a  business  culture  that  separates  the  various  functional  areas  within  the  organization. 

There  has  also  been  an  organizational  reluctance  to  interact  with  the  customers  and  suppliers.  The 
IPD  management  philosophy  requires  that  all  barriers  be  tom  down  so  that  integrated  decision 
making  can  occuT.  This  requires  a  change  in  the  culture  that  drives  the  day  to  day  operation  of  the 
organization. 

To  have  the  most  chance  for  success,  senior  management  must  lead  this  cultural  change 
through  leadership  by  example.  If  the  senior  leaders  do  business  in  an  integrated  fashion,  they  will 
have  a  powerful  effect  on  the  actions  of  the  entire  organization.  Additionally,  the  empowerment 
process  can  only  begin  at  the  top  of  the  organization.  It  is  there  that  the  first  steps  must  be  taken  to 
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release  the  reins  of  control  to  give  the  authority  and  responsibility  to  the  people  that  know  the 
products  best. 

Framework.  A  management  framework  that  emphasizes  IPD  is  essential  for  facilitating  a 
change  in  the  business  culture.  The  traditional  culture  has  created  organizations  that  are  structured 
along  functional  lines  and  management  tools  that  suboptimize  a  particular  function  while  making  it 
difficult  to  communicate  with  other  functions.  For  the  IPD  management  philosophy  to  work, - 
organizations  should  bring  all  resources  to  bear  on  the  products  it  delivers  to  its  customers. 
Management  tools  should  be  integrated  to  facilitate  communication  between  functions  mid  create  a 
decision  making  process  that  emphasizes  teaming  and  upfront  planning.  Chapter  2  of  this  guide 
presents  approaches  to  applying  this  management  framework  at  various  points  in  a  system's  life 
cycle  and  Chapter  3  provides  detailed  guidance  on  organizational  structure  and  the  use  of  Integrated 
Product  Teams  (IPTs). 
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Chapter  2  -  Applications 

The  following  modules  present  approaches  to  implementing  an  IPD  framework  at  different 
phases  in  a  system's  life  cycle.  The  modules  are  designed  to  build  upon  existing  tools  such  as  the 
Air  Force  Acquisition  Model.  Where  appropriate  the  modules  will  refer  to  the  existing  tools  for  - 
further  guidance  and  direction.  Most  of  these  tools  can  be  easily  obtained  through  our  local  staff 
organizations. 

Module  1  -  New  Acquisitions 

General  Principles 

The  success  of  implementing  IPD  largely  depends  on  our  ability  to  create  an  effective 
framework  for  the  program.  In  a  new  acquisition,  this  framework  is  established  in  the  Request  for 
Proposal  (RFP).  The  RFP  identifies  the  detailed  requirements  for  the  system  and  defines  how  the 
government  plans  to  manage  the  program  and  execute  a  contract.  It  is  imperative  that  an  appropriate 
amount  of  upfront  planning  occur  prior  to  RFP  release  since  changing  the  framework  after  contract 
award  not  only  will  incur  excessive  costs  but  will  impose  an  unacceptable  amount  of  risk  on  the 
program. 

Perhaps  the  key  to  performing  effective  upfront  planning  is  the  membership  of  the  RFP 
preparation  team.  An  RFP  should  be  developed  with  the  same  people  that  will  manage  the  contract 
after  the  source  selection.  The  team  membership  should  not  only  include  the  project  officers  and 
Integrated  Product  Teams  (IPTs)  that  will  constitute  the  core  of  the  organization  managing  the 
contract,  but  also  have  representatives  from  the  senior  management  and  staff  organizations. 
Additionally,  customer  representatives  should  be  considered  part  of  the  team  since  the  successful 
application  of  their  requirements  will  truly  dictate  the  success  of  a  program. 

Another  important  element  of  proper  planning  in  the  RFP  process  is  the  involvement  of  the 
suppliers,  which  in  most  cases  are  corporations  in  the  defense  industry.  In  addition  to  helping  them 
understand  our  requirements  prior  to  source  selection,  an  effective  line  of  communication  with 
industry  prior  to  release  of  the  RFP  will  provide  feedback  which  will  greatly  enhance  the  quality  of 
the  RFP.  We  should  never  lose  sight  of  the  fact  that  the  contractor  is  the  true  expert  on  developing 
and  producing  the  system  we  require. .  Inmost  cases,  communication  beyond  the  traditional  xiraft 
RFP  should  occur.  Regular  meetings,  incremental  release  of  RFP  elements,  and  making  use  of 
electronic  bulletin  boards  to  run  ideas  past  industry  are  all  good  ways  of  making  this  early 
communication  occur.  One  of  the  primary  complaints  of  industry  is  that  RFPs  are  not  well  written 
(i.e.,  poorly  planned)  and  limit  their  ability  to  submit  a  good  proposal  for  source  selection.  As  we 
move  towards  implementing  IPD  throughout  all  our  programs,  it  will  be  essential  that  we  help 
industry  understand  our  needs  and  approaches  to  putting  the  framework  in  place  prior  to  RFP  release 
and  contract  award. 
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The  following  sections  outline  the  general  flow  of  an  acquisition  as  shown  in  Figure  2A.  A 
project  officer  and/or  IPT  should  be  able  to  follow  the  process  presented  and  conduct  an  acquisitioo 
that  is  well  planned  out  and  implements  the  IPD  philosophy. 


Figure  2.1 


Defining  the  Requirement 

Establishing  Customer  Requirements.  The  first  step  in  the  acquisition  process  is 
establishing  the  requirements  of  your  customers.  No  program  has  much  chance  for  success  without 
well-defined  requirements  that  can  be  flowed  down  into  the  products  and  processes  that  m^e  up  tte 
system.  All  of  the  elements  of  the  acquisition  are  at  risk  until  firm  requirements  are  set  down  for  die 
program. 

The  requirements  process  begins  by  identifying  your  customers.  The  most  obvious  customer 
is  the  organization  that  will  actually  operate  the  system  once  it  is  fielded  (e.g.  AFSPACECOM). 

Most  of  the  current  requirements  process  is  based  on  receiving  input  from  this  operator.  You  should 
not,  however,  treat  the  operator  as  your  only  customer.  Other  customers  include  the  hea^uarters, 
the  local  staff  agencies,  and  other  government  agencies.  Each  of  these  customers  have  requirements 
that  must  be  met  for  us  to  put  out  an  RFP  and  run  an  acquisition  program.  In  fact,  the  contractors 
can  be  considered  a  customs  in  tiie  RFP  process  since  they  must  understand  our  requirem^ts.  You 
also  should  not  forget  that  you  are  your  own  customer  since  you  will  have  to  manage  the  contract 
you  are  creating. 

With  the  list  of  customers  assembled,  the  next  step  is  to  actually,  gather  thejequirements.  Fot 
some  customers,  like  the  operator,  formal  processes  are  already  in  place  to  begin  this  process.  For 
instance,  the  operator  should  already  have  an  approved  Mission  Need  Statement  (MNS)  and 
Operational  Requirements  Document  (ORD).  For  other  customers,  a  process  will  have  to  lx 
established  for  gathering  requirements.  One  process  that  works  well  for  this  is  called  Quality 
Fxmction  Deployment.  This  tool  provides  a  systematic  approach  to  understanding,  prioritizing  and 
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documenting  customer  requirements.  A  more  detailed  description  of  this  tool  can  be  found  in 
Appendix  2. 

The  key  to  effectively  gathering  requirements  from  any  customer  is  communication.  It  is  -  - 
important  to  develop  a  strong  team  relationship  tvith  all  customers  so  that  the  flow  of  information  is 
not  only  timely,  but  useful.  Many  customers  will  wait  until  the  last  minute  to  present  their 
requirements  (i.e.  during  a  review  process)  if  they  don't  feel  like  they  are  part  of  the  team  fix)m  the 
beginning.  Spending  the  time  up  front  to  get  good  requirements  will  save  countless  days 
downstream  trying  to  correct  everything  you've  done  for  a  customer  requirement  that  was  not  - 
identified  or  ignored. 

Translating  Customer  Requirements.  You  should  always  concentrate  on  gathering  the 
minimum  requirements  necessary  to  field  the  system.  Requirements  should  be  performance- 
oriented.  In  other  words,  the  requirements  should  describe  the  way  the  system  must  function  once  it 
is  fielded.  This  will  give  the  program  the  necessary  flexibility  to  design  the  best  system.  You 
should  avoid  "how-to"  types  of  requirements  that  constrain  the  acquisition  unnecessarily.  You 
should  document  these  performance-oriented  requirements  in  a  functional  specification  like  the 
system  specification  described  in  Mil-Std-490.  The  system  specification  will  be  the  cornerstone  of 
the  acquisition  since  the  rest  of  the  RFP  will  provide  the  tasking  and  contractual  vehicles  to  meet  its 
requirements. 

Preparation  of  the  system  specification  should  occur  concurrently  with  the  preparation  of  the 
operator's  ORD.  In  addition  to  saving  the  time  associated  with  serial  prepeiration,  preparing  the 
documents  in  parallel  allows  the  operator  to  run  the  requirements  by  the  acquisition  personnel  prior 
to  finalizing  their  ORD.  It  also  gives  you  a  chance  to  work  closely  with  the  operator  to  ensure  that 
the  requirements  are  correctly  translated  into  specification  language. 

The  system  specification  should  be  prepared  during  the  Concept  Exploration  (CE)  and 
DemonstrationA^alidation  (DenWal)  phase  of  the  program.  You  should  provide  a  baselined  system 
specification  to  the  offerors  as  part  of  the  Engineering  and  Manufacturing  Development  (EMD) 
phase  RFP.  The  offerors  should  then  be  required  to  submit  system  segment  specifications  as  part  of 
their  EMD  proposals.  This  direction  belongs  in  Section  L  of  the  RFP  as  part  of  the  specific 
instructions  to  the  offerors.  The  purpose  of  having  the  offerors  prepare  and  submit  segment 
specifications  is  to  see  how  each  offeror  breaks  their  system  into  products  and  how  the  system-level 
functional  requirements  are  allocated  to  each  of  the  products. 

Outlining  the  Program 

The  next  step  in  the  acquisition  process  is  to  outline  the  program  vrith  respect  to  the  products 
of  the  system.  One  of  the  fundamental  tenets  of  IPD  is  product  orientation  where  all  activities  in  the 
program  are  focused  on  the  products  that  are  actually  delivered  to  the  operator.  You  should  break 
out  the  products  to  a  level  commensurate  with  the  risk  associated  with  acquiring  the  product.  In 
most  cases,  it  is  sufficient  to  break  down  the  products  two  levels  below  the  overall  system.  The 
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will  break  out  the  products  to  a  lower  level  in  the  proposal  and  provide  a  specification  tree  that 
follows  the  same  breakout.  A  sample  breakout  is  provided  in  Figure  2.2. 


Figure  2.2 


You  may  also  have  to  identify  some  of  the  management  processes  that  apply  to  multiple 
products,  especially  those  that  integrate  the  products  into  a  complete  system  and  control  the 
contractor's  interactions  with  the  government.  Examples  might  be  integration  working  groups  , 
program  reviews,  configuration  management,  data  management,  and  cost  reporting.  These  processes 
need  to  be  identified  since  they  will  flow  into  the  RFP. 

Using  this  data,  you  prepare  a  Work  Breakdown  Structure  (WBS).  The  WBS  should  mirror 
the  product  breakout  and  provide  a  numbering  system  that  will  flow  through  the  entire  RFP.  The 
overall  system  being  procured  becomes  the  Level  1  WBS  and  the  products  underneath  the  system 
become  the  lower  level  WBS  elements.  This  is  consistent  with  the  examples  in  Mil-Std-881.  WBS 
elements  should  also  he  provided  for  the  processes  mentioned  above.  However,  the  process  element 
should  be  inserted  below  the  product  that  it  serves.  For  instance,  since  systems  engineering 
integrates  Level  2  products  into  a  complete  Level  1  system,  it  would  become  a  separate  Level  2 
WBS  element  called  Systems  Engineering/Program  Management.  The  key  is  to  avoid  breakouts 
based  on  the  functions  within  the  program  since,  under  the  IPD  philosophy,  the  product  breakouts  are 
cross-functional. 

The  WBS  should  also  establish  a  numbering  system  that  will  serve  as  a  baseline  for 
developing  the  rest  of  the  RFP.  The  numbers  are  usually  4-  or  5-digits  without  periods  in  between. 
For  instance,  if  the  first  Level  2  product  is  the  Space  Vehicle,  it  might  be  numbered  1000  under  the 
overall  system  0000.  The  first  sub-product  under  the  Space  Vehicle  would  then  be  numbered  1 100. 
An  example  of  this  numbering  system  can  be  found  in  Figure  2.3. 
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Example  Work  Breakdown  Schedule 


0000  Space  System 

1000  Space  Vehicle 

1100  Spacecraft 

1200  Sensor  Payload 

1300  Orbital  Insertion  System 

1400  Systems  Engineering  and  Integration 

2000  Launch  Vehicle 


3000  Ground  System 


4000  Support  System 

5000  Systems  Engineering/Program  Management 


Figure  2.3 

Establishing  a  preliminary  product-oriented  organization  is  the  next  step  in  the  process. 

Since  you  will  manage  the  program  with  a  product  focus  and  develop  the  RFP  like  you  plan  to 
manage  the  program,  it  makes  sense  to  establish  teams  of  people  that  will  address  the  requirements 
of  each  product  and  translate  those  requirements  into  the  RFP.  To  support  the  IPD  philosophy,  these 
teams  should  be  cross-fimctional  in  nature.  That  means  that  each  product  team  will  contain  the 
resources  to  address  all  the  functional  specialties  that  will  play  a  role  in  the  acquisition  of  that 
product.  For  example,  the  team  should  have  representatives  from  program  management, 
engineering,  manufacturing,  logistics,  contracting  and  financial  management.  The  membership  of 
the  team  will  be  dependent  on  the  maturity  of  the  program.  Obviously,  a  product  team  in  a 
production  program  would  require  fewer  design  engineers  than  manufacturing  specialists.  The  team 
should  also  have  a  leader  that  is  selected  using  the  guidelines  from  Chapter  3.  This  organizational 
structure  will  eventually  be  aligned  with  the  winning  contractor's  organization  and  finalized  to 
become  the  SPO's  organization  during  the  execution  of  the  contract. 

Planning  the  Program 

One  of  the  key  tenets  of  IPD  is  upfront  planning.  Since  altering  contracts  is  not  easy,  most  of 
this  planning  should  occur  prior  to  contract  award.  Their  are  several  goals  to  this  upfront  planning 
activity.  The  first  is  to  define  the  core  program  that  must  be  accomplished.  The  core  program 
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consists  of  those  activities  that  you  must  perform  to  have  a  program.  The  second  goal  is  to  put  in 
place  an  integrated  management  framework.  It  is  important  that  you  set  up  the  entire  program 
around  this  framework  to  ensure  that  IPD  flourishes  and  the  program  is  easier  to  manage.  Finsdly, 
the  core  program  risk  must  be  evaluated  to  allow  adequate  resources  to  be  allocated. 

Define  the  Core  Program.  The  first  step  in  the  planning  process  is  to  define  the  key 
program  events  that  must  occur  throughout  the  life  of  the  program.  The  type  of  event  will  depend  on 
the  phase  the  program  is  in.  For  instance,  a  key  event  during  the  design  phase  might  be  the  critical 
design  review  while  a  key  event  during  production  might  be  the  completion  of  acceptance  testing. 
Events  may  also  be  nonrecurring  or  recurring.  For  example,  there  may  be  key  events  during  the 
production  phase  that  will  recur  each  time  the  system  is  manufactured.  These  key  events  should  be 
provided  to  the  offeror  in  Section  L  of  the  RFP.  The  offerors  may  add  key  events  to  the  list  if 
required  by  the  unique  system  they  will  propose.  . 

Once  the  events  have  been  established,  you  should  define  the  work  that  must  be 
accomplished  to  get  to  each  event.  In  the  RFP,  this  work  is  defined  in  an  example  Statement  Of 
Work  (SOW)  that  you  will  provide  to  the  offerors  as  part  of  Section  L,  Proposal  Preparation 
Instructions.  The  key  here  is  to  only  define  the  minimum  requirements  of  the  government.  This  way 
each  offeror  has  the  flexibility  to  define  the  work  for  the  unique  system  it  will  propose  while  still 
meeting  the  government's  minimum  requirements.  Each  offeror  Avill  prepare  a  SOW  and  submit  it  as 
an  attachment  to  the  contract  in  the  source  selection.  The  result  is  a  SOW  written  by  the  people  who 
will  actually  perform  the  work  and  will,  therefore,  achieve  a  greater  deal  of  commitment  from  the 
contractor. 

The  example  tasking  in  the  SOW  should  be  defined  by  product  and  process  using  the 
numbering  system  established  in  the  WBS.  Each  IPT  should  prepare  the  tasking  for  its  product  The 
tasking  for  each  product  should  be  cross-functional  in  nature  and  cover  all  work  that  must  be 
performed  on  that  product  for  the  life  of  the  program.  This  tasking  will  serve  as  a  major  element  of 
the  tool  kit  that  each  IPT  will  use  to  manage  the  contract  after  award.  A  model  of  the  example  SOW 
for  Section  L  of  the  RFP  can  be  foimd  in  Appendix  1. 

Establish  an  Integrated  Management  Framework.  The  next  step  in  the  planning  process 
is  to  have  the  offeror  describe  to  you  how  they  will  accomplish  the  work  in  the  SOW  and  tie  the 
work  to  the  key  events  defined  earlier.  The  vehicle  the  offeror  will  use  is  the  Integrated  Master  Plan 
(IMP).  For  each  product,  the  offeror  will  identify  the  significant  accomplishments  that  must  be  met 
to  complete  the  work  defined  in  tiie  SOW.  Each  significant  accomplishment  is  then  tied  tea  key 
program  event.  Additionally,  the  offeror  will  provide  success  criteria  for  each  significant 
accomplishment  so  that  you  know  how  to  determine  that  the  accomplishment  is  completed.  One 
thing  to  keep  in  mind  is  that  there  is  no  schedule  information  in  the  IMP.  The. IMP  should  be  event- 
driven  and  not  tied  to  any  date.  For  the  source  selection,  the  offeror  will  prepare  an  IMP-  like  the  one 
in  Figure  2.4  and  submit  it  as  an  attachment  to  the  contract. 
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WBS 


SOW 


1 100:  The  contractor  shall  conduct  a 
development  program  to  include 
detailed  design,  manufacture, 
assembly  and  test  of  all  spacecraft 
subsystems. 


Integrated  Master  Plan  | 


Significant  Accomplishments 

Events 

Accomplishment  Criteria 

1100 

PDR 

1.  Preliminary  Design  complete 

X 

la.  Subsystem  perf  reqts  defined 

b.  Duty  cycle  defined 

c.  Prelim  drawings  released 

Figure  2.4 


You  will  find  that  there  are  SOW  teisks,  especially  for  management  processes,  that  do  not  fit 
well  in  the  above  IMP  format.  For  instance,  it  may  be  difficult  for  the  offeror  to  identify  an  event  or 
significant  accomplishment  for  configuration  management.  It  is  important  that  these  processes  are 
also  properly  plaimed  prior  to  contract  award.  Rather  than  requiring  the  IMP  format  described 
above,  you  should  request  that  the  offeror  prepare  a  separate  narrative  section  within  the  IMP.  This 
narrative  should  describe  the  offerors  approach  to  performing  the  process  and  identify  any 
?  relationships  or  interactions  with  the  program  office  or  other  government  personnel.  It  should  also 
identify  any  governing  documents.  The  narratives  are  usually  limited  to  5  pages  and  are  submitted 
as  part  of  the  IMP  during  source  selection.  After  contract  award,  these  narratives  will  become  part  of 
the  contract  along  with  the  rest  of  the  IMP. 

The  direction  to  the  offeror  to  prepare  the  IMP  should  occiu:  in  Section  L  of  the  RFP.  These 
instructions  should  explain  what  an  IMP  is,  provide  guidelines  for  developing  the  IMP,  and  provide 
an  example  format.  You  should  also  provide  a  brief  IMP  instruction  under  each  WBS  element  .in  the 
example  SOW  that  describes  the  desired  scope  of  the  IMP  for  that  product  and  identifies  any  nnique 
IMP  requirements  the  government  might  have  such  as  narratives.  An  IMP  should  be  required  for 
each  phase  of  the  program  from  Concept  Exploration  through  Production. 


0000  Space  System 


Each  IPT  should  also  identify  any  CDRL  items  required  for  its  product.  Care  should  be  taken 
to  avoid  repeating  the  same  CDRL  item  for  each  IPT.  Those  items  could  probably  be  consolidated 
into  single  DD  Formsl423  with  each  interested  IPT  on  the  distribution  list. 
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There  are  two  CDRL  items  that  must  be  developed  for  the  RFP  that  are  major  elements  of  the 
IPD  tool  kit.  They  are  the  Integrated  Master  Schedule  (IMS)  and  Technical  Performance  Measures 
(TPMs).  The  Integrated  Master  Schedule  is  usually  received  about  once  a  month  from  the  contractor 
and  puts  a  date  to  the  events  and  activities  described  in  the  IMP.  An  example  of  the  IMS  and  its 
flowdown  from  the  IMP  is  shown  in  Figure  2.5.  The  TPMs'are  measures  of  the  technical  maturity  of 
the  system  and  serve  as  an  important  tool  for  the  IPT  to  track  the  progress  of  the  system.  The  offeror 
should  be  required  to  provide  the  first  submittal  of  each  of  these  CDRL  items  with  the  proposal. 

Each  IPT  should  identify  to  the  offeror  any  TPM's  that  it  feels  are  mandatory  for  managing  the 
development  of  the  product. 


Integrated  Master  Plan 


Significant  Accomplishments 

Events 

Accomplishment  Criteria 

1100 

PDR 

la.  Subsystem  perf  reqts  defined 

b.  Duty  cycle  defined 

c.  Prelim  drawings  released 

1.  Preliminary  Design  complete 

X 

Integrated  Master  Schedule 


19XX 

Detailed  Task  Program  Events 

PDR  A. 

1100 

la.  Subsystem  performance  requiremens  defined 

b.  Duty  cycle  defined 

c.  Preliminary  drawings  released 

A 

A 

A 

A 

A 

Figure  2.5 


At  this  point,  the  Rf  P  is  ready  for  release.  Prior  to  releasing  the  final  RFP  and-ceasing  all 
discussion,  it  is  important  that  you  feel  comfortable  with  the  offeror's  understanding  of  your 
requirements  in  the  RFP.  The  upfront  planning  that  the  offeror's  will  do  prior  to  source  selection  will 
be  extensive  and  a  great  deal  of  it  will  be  put  on  contract  at  award.  If  the  offeror  prepares  its 
proposal  with  a  misimderstanding  of  the  requirements,  you  will  go  through  a  great  deal  of  pain  trying 
to  fix  it  after  contract  award. 
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Conducting  Source  Selection 

The  offerors'  proposals  will  come  back  with  an  integrated  IPD  "tool  kit"  using  the  single 
numbering  system.  To  take  advantage  of  this  package,  the  source  selection  should  be  conducted 
under  the  same  framework  that  developed  the  RFP.  The  areas  of  evaluation,  therefore,  should  match 
the  WBS  structure,  and  the  evaluation  teams  should  be  the  IPTs  (including  the  product  integration 
team)  that  will  run  the  program  after  contract  award.  The  exception  to  this,  however;  is-the-cost  «  - 
evaluation.  Due  to  regulatory  constraints,  each  IPTs  cost  manager  will  be  detailed  to  a  cost  teamto 
perform  an  independent  evaluation.  You  will  also  be  required  to  have  a  past  performance  evaluation 
team  that  should  have  adequate  representation  from  the  various  IPT's  and  functional  specialties. 

The  IPT's  should  develop  items  and  evaluation  standards  prior  to  source  selection  that  focus 
on  the  offeror's  approach  to  meeting  the  requirements  of  each  product.  The  actual  evaluation  will 
then  rely  heavily  on  the  information  provided  in  the  offeror's  SOW  and  IMP  since  these  documents 
will  reflect  each  offeror's  unique  approach.  Traditional  proposal  volumes  should  also  be  required 
from  the  offeror's  for  each  WBS  element  to  provide  supporting  information  on  the  offeror's  particular 
approach. 

In  many  cases,  you  will  require  more  people  on  the  IPTs  during  source  selection  than  you 
needed  to  write  the  RFP.  If  this  is  the  case,  it  is  important  that  the  new  people  be  trained  on  the  IPD 
approach  prior  to  entering  the  source  selection.  Details  on  the  types  of  training  that  would  be  useful 
can  be  found  in  Chapter  4. 

Allocating  Resources 

After  awarding  the  contract,  you  and  the  contractor  will  have  to  allocate  adequate  resources 
to  effectively  manage  the  contract  and  perform  the  work.  The  key  here  is  to  base  the  allocation  of  .  . 
people,  dollars  and  schedule  on  the  assessed  risk  of  the  program.  In  other  words,  the  higher  risk 
areas  of  the  program  should  have  a  greater  allocation  of  resources  than  the  lower  risk  areas.  It  is 
important  that  the  government's  allocation  of  the  resources  mirror  the  contractor's  allocation  so  that 
the  management  of  the  contract  can  be  done  in  a  team  fashion  and  make  maximum  use  of  the  IPD 
tools  established  in  the  RFP  phase  of  the  acquisition. 

Develop  the  Organization.  The  process  of  allocating  people  to  run  the  program  results  in  a 
finalized  organization.  The  first  step  in  this  process  is  to  examine  the  products  identified  in  the  RFP. 
You  should  work  with  the  contractor  to  decide  if  an  organization  based  on  those  products  is  the  best 
one  to  run  the  program  now  that  the  details  of  the  system  are  known.  The  goal  is  to  match  file 
government  and  contractor  organizations  so  that  an  IPT  is  really  one  team  with  membership  from 
both  the  contractor  and  government.  This  mirroring  will  make  the  contract  easier  to  manage  using 
the  IPD  "tool  kit."  If  the  government  and  contractor  mutually  decide  to  alter  the  organization  from 
the  RFP,  an  administrative  change  to  the  contract  will  have  to  be  made  to  adjust  the  WBS,  SOW  and 
IMP.  The  second  step  in  the  personnel  allocation  process  is  to  determine  the  proper  manning  for 
each  part  of  the  organization.  This  allocation  should  follow  the  guidelines  identified  in  Chapter  3 
and  also  be  based  on  a  risk  assessment.  For  instance,  if  the  team  assesses  that  the  greatest  risk  in  the 
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spacecraft  is  in  the  attitude  control  thrusters,  a  greater  proportion  of  propulsion  engineers  might  be 
included  in  the  spacecraft  IPX.  It  is  also  important  that  the  IPX  membership  adequately  represent  all 
ftmctions  that  will  bear  upon  the  performance  of  that  product  including  the  users  and  suppliers.  Xhe 
final  personnel  allocation  should  be  agreed  to  by  botii  the  government  and  contractor.  : 

Allocate  Dollars.  Xhe  process  of  allocating  the  dollars  assigned  to  the  program  follows  the 
allocation  of  personnel.  Xhis  allocation  will  have  more  of  an  impact  on  the  contractor  than  the 
government.  One  of  the  tenets  of  IPD  is  to  drive  authority  and  responsibility  to  the  lowest  level  of 
the  organization  commensurate  with  risk.  What  this  means  is  that  the  program  managerjsbauld 
assign  fiscal  responsibility  to  each  IPX  rather  than  allocating  out  by  function.  Xo  the  government 
program  office,  this  simply  affects  the  way  we  manage  the  costs  through  C/SCSC.  Xhe  WBS  and 
C/SC  SC  are  aligned  so  that  the  IPX  can  monitor  the  cost  accumulated  for  its  specific  product.  Xhe 
contractor,  however,  should  give  its  IPXs  the  necessary  budget  to  accomplish  the  tasks  it  must 
perform  to  deliver  its  product.  Xhe  contractor's  IPX  chief  then  has  the  authority  to  allocate  the 
budget  according  to  the  risk  associated  with  developing  and  producing  its  product. 

Allocate  Time.  Xhe  final  allocation  of  resources  involves  assigning  time  to  the  IMP.  The 
contractor  will  perform  the  bulk  of  this  allocation  by  identifying  a  schedule  for  each  of  the 
accomplishments  and  criteria  in  the  IMP.  Xhe  contractor  will  document  this  information  in  die  IMS 
that  is  delivered  to  the  government  as  a  CDRL  item  in  the  contract.  Xhe  government's  role  in  this 
process  is  to  ensure  that  the  contractor's  schedule  meets  the  delivery  schedule  in  the  coiitract  with  tiie 
least  possible  risk.  Xhis  CDRL  item  is  usually  delivered  each  month  and  requires  approval  by  the 
government. 

Tracking  and  Executing  the  Program 

Xhe  tracking  and  executing  of  the  contract  will  undoubtedly  be  the  largest  phase  of  the 
acquisition  effort.  Xhe  key  to  making  this  phase  easier  to  manage  is  effectively  using  the  int^rated 
program  structure.  Xhe  integrated  "tool  kit"  developed  as  part  of  the  RFP  is  now  part  of  the  contract 
(Figure  2.6).  Each  IPX  should  be  using  the  tools  to  focus  on  the  cost,  schedule  and  performance  of 
the  product  it  is  responsible  for.  Xhe  senior  management  of  the  program  needs  to  drive  decisions  tfo 
the  lowest  level  commensurate  with  risk.  In  other  words,  since  the  IPX  is  the  body  of  knowledge 
that  is  the  most  familiar  vdth  its  product,  decisions  affecting  the  performance  of  the  product  diouM 
be  made  by  the  IPX  whenever  appropriate. 
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Figure  2.6 

For  development  programs,  the  value  of  the  TPMs  cannot  be  understated.  The  TPMs  are  the 
true  metrics  for  the  success  of  the  program  in  that  they  indicate  how  well  the  system  meets  the  user's 
requirements.  They  also  help  to  provide  a  balanced  system  view  that  will  reflect  the  effectiveness  of 
the  data  generated  using  the  tools  under  the  single  numbering  system.  In  other  words,  the  adequacy 
of  the  allocation  of  resources  based  on  the  initial  risk  assessment  will  be  apparent  from  the  technical 
maturity  of  the  system  evidenced  in  the  TPM  data.  Since  the  allocation  of  resources  is  an  ongoing 
process,  the  IPTs  and/or  senior  management  can  make  adjustments  based  on  this  information. 

The  success  of  the  program  will  also  depend  heavily  on  the  exchange  of  information  between 
the  program  office,  the  contractors,  and  the  user.  It  is  important  that  the  necessary  steps  be  taken 
early  to  establish  a  process  of  open  data  exchange.  Although  the  method  of  exchange  will  depend  on 
the  unique  conditions  of  the  program,  the  methods  can  range  from  regular  meetings  with  all  parties 
to  complex  management  information  systems.  At  the  very  least,  however  there  needs  to  be  an 
effective  way  to  transfer  documents  between  the  program  office  and  contractor  to  avoid  lengthy 
review  processes  that  may  hold  up  the  program. 

Finally,  an  ongoing  training  program  must  be  established  that  will  refresh  the  existing.  :  . . 
team  members  and  educate  the  new  members  on  the  details  of  the  IPD  approach.  Since  this 
approach  to  program  management  varies  from  some  of  the  more  traditional  approaches,  the  team 
members  need  to  receive  this  training  so  that  they  understand  how  to  make  maximum  use  of  the 
IPD  "tool  kit"  and  realize  the  full  benefit  of  the  IPD  approach.  This  training  especially  applies  to 
the  senior  management  within  the  program  office  since  the  IPTs  will  find  it  difficult  to  manage  in 
a  manner  different  from  their  superiors.  Guidelines  on  the  type  of  training  that  should  be 
conducted  can  be  found  in  Chapter  4. 
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Module  2  -  Existing  Acquisitions 

While  it  may  be  easiest  to  institute  the  IPD  management  philosophy  on  new  contractual 
efforts,  ongoing  acquisition  programs  can  also  derive  many  benefits.  Product  orientation  is  a 
fimdamental  tenet  of  IPD  that  can  be  applied  to  anyxirganization.  The  introduction  of  IRTs  as 
described  in  Chapter  3  will  focus  the  orgamzation  on  its  products  and  facilitate  cross-functional 
interaction.  Program  data  can  be  integrated  with  the  IPTs,  improving  the  decision  making  |wocess. 
All  this  can  lead  to  reduced  time,  reduced  cost  and  improved  quality  for  the  remainder  of  the 
program.  The  emphasis  on  integrated  teamwork  and  decision-making  can  also  facilitate  m  '  - 
implementing  the  principles  of  Integrated  Weapon  System  Management. 

A  key  decision  in  determining  how  to  introduce  IPD  into  an  existing  program  is  whether  or 
not  to  restructure  the  contracts  to  follow  the  framework  of  the  Integrated  Program  Structme 
described  earlier  in  this  chapter.  Of  prime  consideration  here  is  the  amount  of  performance  period 
remaining  on  a  contract.  If  a  contract  is  nearly  complete,  the  effort  needed  for  the  restructure  may 
not  be  worthwhile.  In  that  case,  careful  consideration  and  planning  should  be  devoted  to  developing 
the  "tool  kit"  that  will  be  provided  to  the  teams.  If  a  contract  restructure  is  deemed  appropriate,  liie 
guidance  in  Module  1  applies. 

One  approach  for  introducing  IPD  into  an  existing  program  that  has  worked  well  included 
establishing  a  Steering  Committee  and  a  Working  Group  and  writing  an  IPD  Implementation  Plan 
(See  Appendix  3). 

The  Steering  Committee  consists  of  the  System  Program  Director,  the  functional  directors 
and  key  contractor  managers.  They  provide  overall  guidance  and  approval  to  the  efforts  of  the 
Working  Group  and  determine  the  objectives  of  the  IPD  implementation  effort. 

The  Working  Group  is  made  up  of  people  from  across  the  program  office,  encompassii^  a 
broad  range  of  grades  and  functional  specialties.  The  plan  describes  the  objectives  of  implen^nting 
IPD  and  their  key  management  processes.  It  lists  the  products  of  the  program  and  the  teams  that 
would  be  used  to  manage  them.  The  plan  explains  the  "tool  kit"  that  the  teams  will  use  to  make  cost, 
schedule,  performance  and  support  decisions.  The  plan  also  provides  guidance  on  how  the  teams 
should  work  internally  and  how  they  should  interact  together. 
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Chapter  3  -  Integrated  Product  Teams  (IPTs) 


One  aspect  of  IPD  management  philosophy  is  the  creation  of  an  organization  with  a 
product  orientation  that  facilitates  cross-afunctional  teaming.  At  the  macro  level,  this  entails 
setting  up  a  structure  for  the  organization  that  uses  a  hierarchical  arrangement  of  both 
Integrated  Product  Teams  (IPTs)  and  functional  staff.  The  IPTs  manage  the  products 
delivered  to  the  customer  while  the  functional  staff  maintains  technical  excellence  within  the 
program. 

Organizational  Structure 


The  overall  structure  of  the  organization  can  be  broken  down  into  two  levels,  the 
system  level  and  the  product  level,  as  shown  in  Figure  3.1. 


Figure  3.1 

System  Level.  The  system  level  of  the  organization  consists  of  the  Program  Manager 
and  the  functional  directors.  The  functional  directors  perform  five  major  roles  within  the 
organization. 

First,  the  functional  directors  serve  as  the  system-level  IPT  along  with  the  Program 
Manager  and  IPT  team  leaders.  In  this  capacity,  they  act  as  a  cross-functional  team  to  advise 
the  Program  Manager  on  issues  that  affect  overall  system  performance  and  ensure  that  the 
various  products  within  the  organization  integrate  into  the  top-level  system. 
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Second,  they  are  responsible  for  managing  the  personnel  aspects  of  their  discipline  in  - 
the  program  office.  They  provide  qualified  people  to  support  the  IPTs.  They  are  responsible 
for  the  continuing  professional  development  and  training  of  their  people  assigned  to  IPTs. 

Functional  chiefs  are  also  responsible  for  the  technical  excellence  of  their  functional 
area.  They  should  continuously  strive  to  improve  the  processes  that  are  being  used  within  the 
IPTs  to  manage  the  product.  They  should  also  keep  abreast  of  developments  outside  die  -  - 
organi2ation  that  may  affect  their  processes  and  the  overall  system.  These  developments  may 
include  policy  changes,  legal  developments  or  technical  breakthroughs.  For  example,  the  . . 
director  of  contracting  would  strive  to  continuously  improve  the  contract  management 
processes  used  by  the  IPTs  as  well  as  keeping  a  breast  of  changes  to  the  FAR. 

In  addition,  functional  chiefs  would  provide  a  home  for  adjimct  team  members  that 
are  not  physically  located  with  a  single  IPT.  As  a  part  of  the  normal  management  of 
resources  within  an  organization,  there  will  be  times  when  people  must  be  shared  among 
IPTs,  especially  when  they  possess  very  specialized  skills  or  are  very  limited  in  number. 

Lastly,  the  functional  directors  interact  with  higher  headquarters  personnel  and  senior 
representatives  from  customers  and  suppliers  on  issues  relating  to  the  overall  system. 

Product  Level.  The  product  level  of  the  organization  consists  of  a  hierarchy  of  IPT's 
that  report  directly  to  the  Program  Manager.  These  IPTs  are  empowered  with  the  authority 
and  responsibility  to  deliver  their  product  to  the  customer.  For  the  lower-level  IPTs,  the 
customer  is  the  next  higher  level  product.  For  example,  the  customer  of  an  IPT  responsible 
for  the  space  vehicle  payload  would  be  the  IPT  responsible  for  the  overall  space  vehicle. 

This  hierarchy  is  followed  to  the  highest  level  IPT  whose  responsibility  is  to  deliver  the 
product  to  the  end  customer.  In  most  cases,  this  is  the  system-level  IPT  and  the  customer  is 
the  operating  command. 

To  determine  the  level  of  IPT  breakout,  the  program  manager  should  analyze  the  risk 
associated  with  each  product.  A  product  that  possesses  a  high  degree  of  risk  to  satisfying  the 
needs  of  the  customer  would  justify  the  creation  of  sub-product  IPTs.  On  the  other  hand,  a 
product  that  possesses  little  risk  may  be  managed  at  a  higher  level.  The  guiding  tenet  here  is 
that  the  organization  is  broken  out  by  products  and  not  by  the  functions. 

Another  aid  to  the -successful  implementation  of  this  hierarchical  structure  is  a  focus 
on  integration.  An  integration  team  at  each  level  can  help  the  IPTs  at  that  level  ensure  their 

individual  products  will  successfully  integrate  into  the  next  higher  level  product.  For . 

example,  an  integration  team  would  ensure  that  the  payload  and  spacecraft  integrate  into  the 
space  vehicle.  The  role  of  this  integration  team  is  not  to  perform  the -integration,  however, 
but  to  facilitate  discussion  between  the  IPTs. 
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IPX  Membership 


To  be  effective,  an  IPT  must  include  representatives  from  all  the  relevant  disciplines 
that  play  a  significant  role  in  the  performance  of  the  product  and  be  facilitated  by  a  strong 
leader. 


Team  Members.  Selection  of  the  appropriate  team  members  will  depend  on  the 
unique  characteristics  of  the  product  in  terms  of  performance  and  risk.  The  first 
consideration  must  be  given  to  any  discipline  that  has  an  effect  on  the  performance  and  life, 
cycle  support  of  the  product.  Representation  from  these  disciplines  is  necessary  to  ensure 
that  integrated  decisions  are  made  and  sequential  processes  are  avoided.  However,  the  team 
should  be  kept  to  a  manageable  size  to  be  effective  (8- 10' members  is  a  good  goal).  The 
selection  of  the  full-time  team  members,  therefore,  will  depend  on  the  risk  associated  with 
the  product .  The  team  must  examine  the  product  to  determine  which  disciplines  present  the 
most  risk  to  its  success  and  select  the  team  members  based  on  this  information. 

IPTs  will  likely  have  two  types  of  members:  core  and  adjunct.  Core  members  are  the 
full-time  members  of  the  IPT;  adjunct  mernbers  participate  on  a  part-time  or  as  needed  basis. 
While  co-location  facilitates  the  most  effective  communication  within  a  team,  there  will  be 
times  when  a  given  discipline  is  not  represented  on  a  full  time  basis.  This  situation  may 
occur  if  a  person  with  specialized  knowledge  is  required  by  multiple  teams  or  if  the  risk  or 
workload  associated  with  that  discipline  did  not  justify  full  time  membership,  or  if  a  team 
member  (eg.  ALC  member,  contractor)  works  in  another  location  or  city.  In  both  cases,  a 
form  of  matrix  management  must  be  used.  The  functionjal  directors  will  control  the 
allocation  of  these  people,  and  any  team  personnel  requirement  will  have  to  be  worked  with 
them  directly. 

It  should  also  be  noted  that  physical  co-location  is  the  preferred  approach  when 
setting  up  IPTs.  Co-location  opens  and  maintains  frequent  channels  of  communication  that 
are  lost  if  team  members  are  located  in  other  buildings  and  only  attend  meetings.  However, 
the  establishment  of  daily  meetings,  continuous  sharing  and  understanding  of  ideas  and  the 
formation  of  sub-groups  to  work  on  particular  issues  can  help  alleviate  this  problem. 

Team  Leader.  The  role  of  the  team  leader  is  to  keep  the  team  focused  on  integration 
and  decision-making.  The  team  leader  is  not  necessarily  the  supervisor  of  the  team. 
Consensus  decision-making  is  encouraged.  With  this  role,  the  selection  of  an  effective  team . 
leader  is  crucial  to  the  successful  functioning  of  the  team.  While  some  individuals  can  be 
good  managers  or  experienced  technicians,  they  may  not  be  able  to  function  as  an  effective 
leader  of  an  IPT.  There  are  several  factors  that  should  be  considered  when  selecting  a  team 
leader: 

Team  plaver.  The  team  leader  should  be  able  to  guide,  encourage  and  coach  the 
team's  operation.  The  team  leader  should  have  the  attributes  of  effective  leadership,  tact. 
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diplomacy,  competence,  and  the  ability  to  listen  and  move  the  group  towards  consensus.  The 
leader  should  help  the  team  to  achieve  balanced,  integrated  decisions  withtiut  dominating  the 
process. 

Communication  skills.  The  team  leader  should  be  an  effectivexommimicator.  The  . 
leader  should  be  able  to  advocate  the  teams  conclusions  and  recommendations  to  others  and 
to  work  effectively  within  the  framework  of  the  next  higher  level  IPT  in  the  organization.  . . . 

Broad  knowledge.  The  team  leader  should  be  familiar  with  the  various  disciplines 
that  affect  the  performance  of  the  product  they  are  responsible  for.  This  will  enhance  die  ■ "  - 
cross-functional  interaction  within  the  IPT  and  help  ensure  that  the  decision  making  process . 
does  not  become  dominated  by  one  discipline. 
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Chapter  4  -  Training 

The  single  most  important  factor  contributing  to  IPD  success  is  education  and  training  in  the 
IPD  management  philosophy.  IPD  is  a  new  way  of  doing  business,  a  cultural  change.  As  such,  the 
entire  program  team  needs  to  understand  the  basic  JPD^pproach,  its  benefits,  and  hoW  to  apply  it.  _ 
This  training  should  be  conducted  as  a  series  of  building  blocks,  with  each  session  building  on  the 
last.  A  combination  of  formal  briefing  and  hands-on-training  is  recommended.  Program  offices  are 

encouraged  to  use  their  own  facilitators  or  trainers  as  much  as  possible.  The  Acquisition  . ,  ,  - 

Development  Organization  (SDS)  can  assist  with  the  IPD  training.  The  continuous  improvement 
office  (TQ)  can  recommend  team  building  tools  and  a  team  building  approach.  (The  following  types 
of  training  serve  as  a  guide  each  organization  can  tailor  to  its  unique  situation). 

Awareness  Training 

All  members  of  the  organization  should  receive  awareness  training  to  familiarize  them  with 
the  IPD  management  philosophy.  This  training  should  have  three  parts:  program  specific,  IPD 
philosophy,  and  teambuilding.  The  program  specific  training  should  assure  that  everyone  has  a 
common  vision  and  understanding  of  the  customer's  requirements  and  the  organization's  purpose  and 
products.  Next  is  an  overview  session  on  IPD  philosophy  and  an  introduction  to  the  tools  and 
techniques  used  to  implement  this  management  philosophy.  Finally,  teambuilding  exercises  should 
be  conducted  to  bring  the  organization  together  as  a  whole  and  to  facilitate  the  cultural  change.  The 
organization's  customers  and  suppliers  should  be  included  in  these  presentations  whenever  possible. 

Team  Training. 

As  IPTs  are  formed,  training  should  occur  that  builds  upon  the  awareness  training.  First,  it  - 
should  provide  detailed  guidance  on  the  implementation  of  the  IPD  management  philosophy  as  it 
pertains  to  a  specific  team.  This  training  should  also  focus  on  understanding  the  roles  and 
interrelationships  between  the  various  disciplines  and  between  teams,  on  the  participation  of  core 
and  adjunct  members,  and  on  bringing  the  group  together  as  a  team.  The  training  should  identify  the 
team's  customers,  both  internal  and  external,  and  the  products  delivered  to  those  customers.  The 
second  part  should  focus  on  teambuilding.  If  possible,  the  team  should  include  its  customers  and 
suppliers  in  this  training  to  help  build  solid  relationships.  This  training  should  be  repeated  for  new 
team  members  downstream  and  as  a  refresher  for  any  member  of  the  team  who  wish  to  reinforce 
their  understanding  of  the  IPD  management  philosophy  and  the  tools  associated  with  it.  - 

Task  Specific  Training.  The  IPD  philosophy  can  be  introduced  into  a  program  either  at  the 
beginning  of  a  new  contractual  effort  (eg.  RFP,  major  ECP,  program  restructure)  or  into  an  existing 
program  during  its  ongoing  activity.  Before  entering  into  this  effort,  it  is  wise  to  train  the  people 
who  will  be  doing  the  implementation  about  their  objectives,  roles,  and  tasks. 
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New  Contractual  Effort.  The  team  that  will  introduce  IPD  through  a  major  contractual  effort 
needs  to  understand  two  areas:  (1)  their  program  and  (2)  how  IPD  applies  to  the  effort  they  are  about 
to  undertake. 

Regarding  their  program,  the  team  needs  to  imderstand  the  core  requirements  of  the  program, 
both  in  terms  of  customer  requirements  and  Jcey  contractual  programevents.  They  also  need  to 
understand  the  major  products  and  processes  of  their  program  and  how  that  translates  into  an  outline 
of  the  program  in  the  work  breakdown  structure.  This  may  be  a  refresher  on  the  program 
information  presented  in  the  awareness  training. 

If  writing  an  RFP,  the  team  will  need  to  leant  how  to  communicate  the  program  structure  and 
requirements  into  a  draft  SOW,  how  to  write  instructions  on  how  to  propose  an  IMP,  how  to 
determine  which  CDRLs  are  needed,  how  to  structure  their  CLINs,  and  how  to  involve  industry  early 
on  in  the  process.  When  the  proposals  are  received  and  the  team  is  about  to  perform  source 
selection,  they  will  need  to  understand  what  to  expect  in  the  proposals  and  how  to  fairly  evaluate 
what  will  likely  be  very  different  proposals. 

Existing  Programs.  The  basic  awareness  and  team  training  should  provide  most  of  the 
training  needed.  However,  if  the  contracts  are  not  to  be  restructured,  team  members  will  need  to 
leam  where  and  how  to  find  all  the  information  they  will  need  to  manage  their  product.  This  may 
take  the  form  of  a  matrix  that  lists  the  relevant  SOW  tasks,  CLINs,  and  CDRLs,  as  well  as  cost, 
schedule  and  performance  data. 
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Appendix  1  -  Sample  Section  L  Instructions 


Example  1 

1100  Space  Vehicle 

F.Yflmple  Statement  of  Work:  The  contractor  shall  develop,  test  and 
support  a  space  vehicle  system  Oiat  meets  the  system  specification, 
in  accordance  with  the  activities  described  in  the  IMP. 

Integrated  Master  Plan  (IMP):  The  space  vehicle  section  of  the  IMP 
shall  include,  but  not  be  limited  to,  the  steps  required  to  develop, 
test  and  support  the  space  vehicle 

Propngal  Vnliime-  The  offeror  shall  provide  a  description  of  the 
space  vehicle  system. 

Example  2 

6400  Quality  Assurance  Management 

Eyamnle  Statement  of  Work:  The  contractor  shall  implement  a 
quality  assurance  program  that  focuses  on  variability  reduction  and 
is  based  on  Mil-Q-9858A. 

Integrated  Master  Plan  (IMPl:  In  a  narrative  section,  the  offeror 
shall  describe  its  approach  to  quality  assurance  management  using 
Mil-Q-9858A  as  a  framework  and  identify  how  it  will  interact  with 
the  government. 

Proposal  Volume:  No  additional  instructions. 
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Appendix  2  -  Quality  Function  Deployment 


Introduction 

QFD  is  a  process  that  integrates  customer  requirements  into -the  design  -and  development  of 
the  product.  It  is  a  structured,  customer  oriented  process  for  determining,  assessing  and  prioritizing 
system/acquisition's  requirements.  Successive  applications  of  the  QFD  tool  drives  thod^gn  of  the 
product  to  the  level  of  detail  required  by  the  team  to  support  the  "voice  of  the  customer".  Design, 
production  and  support  life  cycle  are  all  considered.  Sometimes  called  the  "house  of  quality" 
because  of  the  appearance  of  the  structure  of  the  diagram  used  to  facilitate  the  inputs  and 
assessments,  QFD  systematically  translates  the  customer  requirements  into  target  values  that  are 
disseminated  to  all  project  personnel.  It  emphasizes  early  participation  of  all  disciplines  and 
functional  representatives  in  product  or  process  development  and  facilitates  cross-functional 
communications. 

QFD,  as  an  approach  to  design,  was  introduced  by  Yoji  Akao  in  1966.  In  1972  Akao’s  ideas 
were  formulated  and  systematized  at  Mitsubishi's  shipyard  in  Kobe,  Japan  for  the  "one-of-a-kind" 
ship  design.  However,  it  has  broad  applicability  to  manufactured  products,  complicated  processes 
and  many  areas  of  service  industries.  Today  QFD  is  a  major  force  in  the  quality  efforts  of  U.S. 
industries,  notably  the  automotive  industry. 

The  approach  of  QFD  can  be  summarized  in  six  steps. 

1 .  The  customer  states  requirements  in  their  own  words. 

2.  Define  the  relationship  between  customer  requirements  and  selected  characteristics 

3.  Convert  customer  requirements  into  specifications,  functional  and  allocated 

4.  From  the  specifications  define  design  requirements 

5.  Define  the  method  and  activities  for  validation  of  customer  requirements 

6.  Feedback  to  the  customer  and  all  participants 

Identifying  Requirements 

The  basic  methodology  of  QFD  is  to  identify  specific  "whats"  of  the  customer  and  translate 
those  items  into  "hows" .  As  the  two  lists  are  developed,  the  interaction  between  the  two  elements 
is  determined  and  the  resolution  of  conflicts  begins.  The  team  formed  to  develop  the 
acquisition/process  identifies  the  customers  and  attempts  to  quantify  the  basic  nature  of  the 
customer  "wants".  The  team  then  develops  lists  of  "hows"  which  will  meet  the  "whats" 
(requirements)  of  the  customer.  The  QFD  process  will  prioritize  the  "hows"  and  identify  conflicts  or 
trade-off  in  the  selection  of  the  "hows".  IPD  uses  the  QFD  to  translate  the  user  requirements  into  a 
system  specification. 
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Getting  the  “Voice”  of  the  Customer 


“Whats” 

“Hows” 

Voice  of  the 

Requirem  ents 

Customer 

that  respond  to 

(User) 

Customer  Needs 

Figure  A.2.1. 

IPD  use  of  QFD  in  Requirements  and  Product  Development 

While  QFD  is  not  a  tool  or  philosophy  unique  to  IPD  approach,  it  is  a  potentially  very  powerful  tool 
that  is  very  much  in  consonance  with  the  philosophies  and  practices  of  both  IPD  and  TQL. 
Following  the  logic  stated  above,  the  design  of  the  system  is  detailed  through  the  successive 
development  of  "houses  of  quality"  using  the  defined  'hows"  as  the  "whats"  of  the  next  house. 


Building  the  House  of  Quality 
(a  matrix  of  whats  vs  hows) 


Whits 


Figure  A.2.2 

In  the  IMP  system,  the  team  develops,  via  brain-storming  or  similar  tools,  the  basic  '.whats".  of  the 
system  or  program.  The  first  set  of 'hows"  developed  represent  the  basic  program  outline  and  are 
translated  into  both  the  user  requirements  document  and  the  outline  of  the  acquisition  program. 
Successive  houses  fijrther  define  the  design  of  the  program  and  allow  the  team  to  identify  conflicting 
interactions  between  the  various  program  requirements.  Successive  houses  identify  program 
structure;  design  and  define  methods  for  meeting  the  requirements  of  the  user  stated  in  his 
operational  requirements  documents.  In  fact,  the  optimum  use  of  QFD  would  be  with  the  user  to 
assist  in  the  development  of  the  basic  requirements.  User/customer  participation  is  crucial. 
Participation  by  knowledgeable  people,  with  significant  decision  making  authority,  is  necessary. 
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This  pertains  to  all  of  the  participants  -  customers/users,  program  office,  and  functional  experts 
(regardless  of  affiliation).  The  process  is  quite  labor  intensive,  and  usually  requires  dedicated 
participation  by  a  fairly  large  number  of  people  for  several  days  or  more.  The  team  that  goes 
through  a  QFD  process  will,  as  individuals,  have  gained  a  great  deal  of  shared  knowledge  about  the 
program,  its  requirements  and  the  other  team  participants  (i.e.,  QFD  can  be  a  team  building  activity). 
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Appendix  3  -  IPD  Implementation  Plan 


(PROGRAM  NAME) 

INTEGRATED  PRODUCT  DEVELOPMENT 
IMPLEMENTATION  PLAN 
(Sample  Outline) 

1.0  OBJECTIVE 

Possible  topics: 

Greater  visibility  into  risk  areas 
Empower  people 

Enhance  trust  and  teamwork  through  govt/industry  teaming 

Improve  planning 

Greater  functional  influence 

Smoother  transition  to  production,  operations  and  support 
Lower  cost,  higher  quality 

2.0  APPROACH 

Possible  topics: 

At  what  level  will  products  be  managed 
At  what  level  will  teams  be  formed 
Role  of  functional  chiefs 

How  will  industry  and  other  govt  agencies  be  incorporated  into  teams 
Will  the  contract  be  restructured 

3.0  PROGRAM  OUTLINE 

3.1  Key  Products 

3.2  Key  Processes 

4.0  TOOL  KIT 

4. 1  Integrated  Master  Plan 

4.2  Integrated  Master  Schedule  (Near  and  Long  Term) 

4.3  Performance 

4.4  Cost 

4.5  Risk  Management 

4.6  Other  Tools  (CLINs,  Clauses,  CDRLs,  Award  Fee,  etc) 

5.0  TEAM  MANAGEMENT 

5 . 1  Empowerment  (Authority,  Responsibility,  Accountability) 

5.2  Role  of  the  Team  Leader 

5.3  Role  of  the  Team  Members 

5.4  Team  Procedures  (Meetings,  govt/industry  interaction,  etc) 

5.5  Integration  between  Teams 
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